Flexible radio link control packet data unit length

ABSTRACT

According to an example method performed in a High Speed Downlink Packet Access (HSDPA) environment, a first device generates a High Speed Downlink Shared Channel (HS-DSCH) data frame that includes a plurality of blocks of packet data units. A first block of the plurality of blocks includes packet data units of a first length, and a second block of the plurality of blocks includes packet data units of a different, second length. The first device transfers the HS-DSCH data frame to a second device. The HS-DSCH data frame further includes, for each block of the plurality of blocks, a first information element that indicates a length of the one or more packet data units in the each block, and a second information element that indicates a quantity of packet data units in the each block.

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.12/525,852 filed on 27 Oct. 2009, which was the National Stage ofInternational Application No. PCT/SE2008/050016, filed 7 Jan. 2008, thedisclosure of which is incorporated herein by reference in its entirety.This application also claims the benefit of Swedish Application No. SE0700302-3, filed 6 Feb. 2007

TECHNICAL FIELD

Embodiments consistent with the present disclosure relate generally towireless communication systems, and more particularly, to data flowcontrol in a mobile communication system.

BACKGROUND

Wideband Code Division Multiple Access Radio Access Network (WRAN)introduced High Speed Downlink Packet Access (HSDPA) in 3GPP Release 5and High Speed Uplink Packet Access (HSUPA)/Enhanced Uplink (EUL) in3GPP Release 6. High Speed Packet Access (HSPA) is the common term forboth HSDPA and EUL. 3GPP specifications from Release 4 to Release 6 usea few fixed Medium Access Control-d (MAC-d) Packet Data Unit (PDU)lengths for HSPA. The Radio Link Control (RLC) transmission windowlimitation of 2,047 PDUs together with the rather long Round-Trip-Time(from the serving radio network controller to user equipment and back)gives a limited peak bitrate in cellular systems.

The introduction of Multiple Input, Multiple Output (MIMO) and/or 64Quadrature Amplitude Modulation (QAM) may result in peak bitrates ashigh as 42 Megabits per second (Mbps). Longer MAC-d PDU lengths areneeded for a higher HSDPA peak bitrate (assuming that the RLC windowsize of 2,047 is maintained). Using MAC-d PDUs that are too long causeslimited coverage, as long as only an integer number of MAC-d PDUs isscheduled over the air-interface in one Transmission Time Interval(TTI), i.e., one MAC-d PDU is the smallest unit of data that can betransmitted in one TTI.

RLC Acknowledged Mode (AM) provides a structure for using flexible PDUlengths. In, for example, RLC AM (3GPP TS 25.322, RLC protocolspecification), a flexible PDU length structure is defined. There is apossibility to configure several RLC PDU lengths, but header fields mayrestrict the de-facto number that can be used. For example, it iscurrently possible to use maximally 8 different MAC-d PDU lengths overHS-DSCH, where a MAC-d PDU includes an RLC PDU and optional MAC-dheader. A completely new PDU length structure is, therefore, needed foroptimal performance.

The current solution for High Speed Downlink Shared Channel (HS-DSCH)capacity allocation and the definition of the HS-DSCH DATA FRAME are notefficient for the flexible RLC (or flexible PDU length structure)solution. The HS-DSCH Data Frame bitrate cannot be controlled well usingthe current HS-DSCH Capacity Allocation Control Frame format. Thecurrent control frame format specifies that a given number of PDUs(HS-DSCH Credits) of given maximum length (Maximum MAC-d PDU Length) canbe sent in a given interval (HS-DSCH Interval). Assuming a fixed MAC-dPDU length, it is easy to translate this format to octets within aninterval, or to a bitrate. However, with the introduction of flexibleRLC, each and every MAC-d PDU can be of different length. Thus, a PDU ofone octet consumes a full credit, just like a PDU of 1,500 octets, andcontrolling the allowed number of octets per interval, or the allowedbitrate, becomes difficult.

The initial capacity of HS-DSCH data transfer is granted by the basestation via the HS-DSCH Initial Capacity Allocation during the RadioLink Setup procedure, the Radio Link Reconfiguration procedure, or theRadio Link Addition procedure. During these procedures, the HS-DSCHInitial Capacity Allocation, which is sent by the base station to thecontrolling radio network controller, specifies the maximum MAC-d PDUlength (Maximum MAC-d PDU Size) and the number of MAC-d PDUs (HS-DSCHInitial Window Size). The current interpretation of this HS-DSCH InitialCapacity Allocation is used for fixed MAC-d PDU lengths and is obviouslynot suitable for flexible RLC.

The current HS-DSCH DATA FRAME format does not support different MAC-dPDU lengths. Sending MAC-d PDUs of different length might become veryinefficient (e.g., the transport network overhead can become very high),because a new DATA FRAME is needed for every PDU of different length.Moreover, in the current format, a 4-bit spare extension is inserted infront of every MAC-d PDU in the data frame, increasing the overheadsignificantly in the case of octet aligned PDUs, which is a common case.The current format cannot handle the flexible RLC approach (e.g., wherea MAC-d PDU containing a 1,500 octets long Internet Protocol (IP) packetis to be sent). At the same time, the current MAC-d PDU length indicatorassumes bit granularity, which is not needed if MAC-d PDUs become octetaligned with the removal of MAC-d multiplexing. Moreover, with theremoval of MAC-d multiplexing, if the HS-DSCH DATA FRAME does notsupport some type of logical channel mapping, the number of transportnetwork connections needed by some Radio Bearers might increasesignificantly (e.g., instead of one connection, four connections may beneeded for a Signaling Radio Bearer (SRB)).

SUMMARY

It is an object of the present disclosure to overcome at least some ofthe above disadvantages and to provide an improved data flow control forcommunication systems.

Embodiments described herein provide a new HS-DSCH framing protocolformat (referred to hereinafter as a “HS-DSCH framing protocol type 2format”) that may allow for transmission of PDUs of differing lengths.In one embodiment, the HS-DSCH framing protocol type 2 format provides anew HS-DSCH framing protocol type 2 CAPACITY ALLOCATION Control Frameformat that specifies MAC-d PDU credits in octets (as opposed to acombination of a number of PDUs of a given maximum length). The HS-DSCHframing protocol type 2 CAPACITY ALLOCATION Control Frame also supportslarger MAC-d PDU lengths by allowing the reuse of unused credits.

In addition to a new CAPACITY ALLOCATION Control Frame format, theHS-DSCH framing protocol type 2 frame format provides a new HS-DSCHframing protocol type 2 DATA FRAME format. The HS-DSCH framing protocoltype 2 DATA FRAME may allow more than one PDU length in the same DATAFRAME. Moreover, the HS-DSCH framing protocol type 2 DATA FRAME formatmay, in one embodiment, allow for the transmission of several PDUsassociated with different logical channels in the same DATA FRAME.

The new HS-DSCH framing protocol type 2 frame format may provide:

-   -   a maximum MAC-d PDU length of ˜1500 octets and octet granularity        in MAC-d PDU length is efficiently supported;    -   ability to take into account the Maximum Transmission Unit        limitation of the used transport network;    -   ability to support flexible MAC-d PDU lengths;    -   ability to support higher High Speed Packet Access (HSPA)        Evolution bitrates (e.g., up to ˜42 Megabits per second (Mbps));    -   small Transport Network Layer overhead (data frame header and        control frame length); and single data frame and control frame        format, making for easier expansion in the future.

According to one aspect of the present disclosure, an example method isperformed by a first device in a HSDPA environment. The first devicegenerates a HS-DSCH data frame that includes a plurality of blocks ofpacket data units. A first block of the plurality of blocks includespacket data units of a first length, and a second block of the pluralityof blocks includes packet data units of a different, second length. Thefirst device transfers the HS-DSCH data frame to a second device. TheHS-DSCH data frame further includes, for each block of the plurality ofblocks, a first information element that indicates a length of the oneor more packet data units in the each block, and a second informationelement that indicates a quantity of packet data units in the each block

Of course, the present disclosure is not limited to the above featuresand advantages. Indeed, those skilled in the art will recognizeadditional features and advantages upon reading the following detaileddescription, and upon viewing the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an exemplary network in which systems and methodsdescribed herein may be implemented.

FIG. 2 is an exemplary diagram of a base station of FIG. 1.

FIG. 3 is an exemplary diagram of a computer-readable medium that may beassociated with the base station of FIG. 1.

FIG. 4 is an exemplary diagram of a radio network controller of FIG. 1.

FIG. 5 is a flowchart of an exemplary process for transmitting a dataframe according to an exemplary embodiment.

FIG. 6 is an exemplary diagram of a High Speed Downlink Shared Channel(HS-DSCH) framing protocol type 2 CAPACITY ALLOCATION Control Frameaccording to an exemplary embodiment.

FIGS. 7A-7E are exemplary diagrams of portions of HS-DSCH framingprotocol type 2 DATA FRAMES according to exemplary embodiments.

FIG. 8 is a flowchart of an exemplary process for determining whether anode is capable of supporting the HS-DSCH framing protocol type 2format.

FIG. 9 is an exemplary flow diagram according to an exemplaryembodiment.

DETAILED DESCRIPTION

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements. Also, the following detailed description does notlimit the present disclosure.

Embodiments described herein provide a HS-DSCH framing protocol(referred to as “HS-DSCH framing protocol type 2”) that allows fortransmission of PDUs of differing lengths.

FIG. 1 is a diagram of an exemplary network 100 in which systems andmethods described herein may be implemented. Network 100 may include agroup of user equipment (UE) 110-1 through 110-L (referred tocollectively, and in some instances individually, as “user equipment110”), a radio access network (RAN) 120, and a core network (CN) 130.Four user equipment 110, one radio access network 120, and one corenetwork 130 have been illustrated for simplicity. In practice, there maybe more or fewer user equipment, radio access networks, and/or corenetworks.

User equipment 110 may include one or more devices capable ofsending/receiving voice and/or data to/from radio access network 120. Inone embodiment, user equipment 110 may include, for example, a wirelesstelephone, a personal digital assistant (PDA), a laptop, etc.

Radio access network 120 may include one or more devices fortransmitting voice and/or data to user equipment 110 and core network130. As illustrated, radio access network 120 may include a group ofbase stations (BSs) 122-1 through 122-M (referred to collectively as“base stations 122” and in some instances, individually as “base station122”) and a group of radio network controllers (RNCs) 124-1 through124-N (referred to collectively as “radio network controllers 124” andin some instances, individually as “radio access controller 124”). Fourbase stations 122 and two radio network controllers 124 are shown inFIG. 1 for simplicity. In practice, there may be more or fewer basestations and/or radio network controllers.

Base stations 122 (also referred to as “Node Bs”) may include one ormore devices that receive voice and/or data from radio networkcontrollers 124 and transmit that voice and/or data to user equipment110 via an air interface. Base stations 122 may also include one or moredevices that receive voice and/or data from user equipment 110 over anair interface and transmit that voice and/or data to radio networkcontrollers 124 or other user equipment 110.

Radio network controllers 124 may include one or more devices thatcontrol and manage base stations 122. Radio network controllers 124 mayalso include devices that perform user data processing to manageutilization of radio network services. Radio network controllers 124 maytransmit/receive voice and data to/from base stations 122, other radionetwork controllers 124, and/or core network 130.

A radio network controller 124 may act as a controlling radio networkcontroller (CRNC), a drift radio network controller (DRNC), or a servingradio network controller (SRNC). A CRNC is responsible for controllingthe resources of a base station 122. On the other hand, an SRNC serves aparticular user equipment 110 and manages the connections towards thatuser equipment 110. Likewise, a DRNC fulfills a similar role to the SRNC(e.g., may route traffic between a SRNC and a particular user equipment110).

As illustrated in FIG. 1, a radio network controller 124 may connect toa base station 122 via an lub interface and to another radio networkcontroller 124 via an lur interface.

Core network 130 may include one or more devices that transfer/receivevoice and/or data to a circuit-switched and/or packet-switched network.In one embodiment, core network 130 may include, for example, a MobileSwitching Center (MSC), a Gateway MSC (GMSC), a Media Gateway (MGW), aServing General Packet Radio Service (GPRS) Support Node (SGSN), aGateway GPRS Support Node (GGSN), and/or other devices.

In some embodiments, one or more components of network 100 may performone or more of the tasks described as being performed by one or moreother components of network 100.

FIG. 2 is an exemplary diagram of base station 122-1 according to anexemplary embodiment. Base stations 122-2 through 122-M may be similarlyconfigured. As shown in FIG. 2, base station 122-1 may include antennas210, transceivers (TX/RX) 220, processing system 230, and lub interface(I/F) 240. Base station 122-1 may include additional and/or differentcomponents than illustrated in FIG. 2.

Antennas 210 may include one or more directional and/or omnidirectionalantennas. Transceivers 220 may be associated with antennas 210 andinclude transceiver circuitry for transmitting and/or receiving symbolsequences in a network, such as network 110, via antennas 210.

Processing system 230 may control the operation of base station 122-1.Processing system 230 may also process information received viatransceivers 220 and lub interface 240. Processing system 230 mayfurther measure quality and strength of connection and determine theframe error rate (FER), and transmit this information to radio networkcontroller 124-1. As illustrated, processing system 230 may include aprocessing unit 232, a group of priority queues 234, and a logicalchannel identifier (ID) to priority queue mapper 236. It will beappreciated that processing system 230 may include additional and/ordifferent components than illustrated in FIG. 2.

Processing unit 232 may process information received via transceivers220 and lub interface 240. The processing may include, for example, dataconversion, forward error correction (FEC), rate adaptation, WidebandCode Division Multiple Access (WCDMA) spreading/dispreading, andquadrature phase shift keying (QPSK) modulation, etc. In addition,processing unit 232 may generate control messages and/or data messages(e.g., HS-DSCH DATA FRAMES) and cause those control messages and/or datamessages to be transmitted via transceivers 220 and/or lub interface240. Processing unit 232 may also process control messages and/or datamessages received from transceivers 220 and/or lub interface 240.

Priority queues 234 may store information (e.g., in the form of PDUs) tobe transmitted to and/or that has been received from user equipment 110.In one embodiment, each user equipment 110 associated with base station122-1 may be associated with one or more priority queues from priorityqueues 234. A priority queue may, for example, be initialized for a userequipment 110 when a MAC-d flow is established for that user equipment110.

Logical channel identifier to priority queue mapper 236 may map receivedlogical channel identifiers to priority queue identifiers. In oneembodiment, a HS-DSCH framing protocol type 2 DATA FRAME may associateone or more logical channel identifiers with one or more PDUs stored inthe DATA FRAME. Base station 122-1 may use the logical channelidentifiers to identify the appropriate priority queues from priorityqueues 234 for storing the PDUs.

lub interface 240 may include one or more line cards that allow basestation 122-1 to transmit data to and receive data from radio networkcontroller 124-1.

In some embodiments, one or more components of base station 122-1 mayperform the tasks described as being performed by one or more othercomponents of base station 122-1.

FIG. 3 is an exemplary diagram of a computer-readable medium 300 thatmay be associated with a base station, such as base station 122-1. Whileone computer-readable medium is described below, it will be appreciatedthat computer-readable medium 300 may include multiple computer-readablemedia stored locally at base station 122-1, or stored at one or moredifferent and possibly remote locations.

As illustrated, computer-readable medium 300 may maintain a group ofentries in the following exemplary fields: a logical channel identifierfield 310 and a priority queue identifier field 320. Computer-readablemedium 300 may maintain additional or different information than thatillustrated in FIG. 3.

Logical channel identifier field 310 may store a sequence of charactersthat identifies a logical channel with which user equipment, such asuser equipment 110-1, is associated. In one embodiment, the sequence ofcharacters may be unique for that particular base station. Priorityqueue identifier field 320 may store a sequence of characters thatidentifies a priority queue in priority queues 234. In one embodiment,each priority queue in priority queues 234 may be associated with aunique sequence of characters that acts as an identifier for thatpriority queue.

Thus, via computer-readable medium 300, base station 122-1 may identifya priority queue based on a received logical channel identifier.

FIG. 4 is an exemplary diagram of radio network controller 124-1according to an exemplary embodiment. Radio network controller 124-2 maybe similarly configured. As shown in FIG. 4, radio network controller124-1 may include a processing system 410, an lub interface 420, an lurinterface 430, and/or other interfaces 440. Radio network controller124-1 may include additional and/or different components than thecomponents illustrated in FIG. 4.

Processing system 410 may control the operation of radio networkcontroller 124-1. As illustrated, processing system 410 may include aprocessing unit 412 that handles protocol exchanges between lubinterface 420, lur interface 430, and other interfaces 440. In addition,processing unit 412 may generate control messages and/or data messagesand transmit those control messages and/or data messages via interfaces420-440. Processing unit 412 may also process control messages and/ordata messages received from interfaces 420-440.

lub interface 420 may include one or more line cards that allow radionetwork controller 124-1 to transmit control messages and/or datamessages to and receive control messages and/or data messages from basestation 122-1. lur interface 430 may include one or more line cards thatallow radio network controller 124-1 to transmit control messages and/ordata messages to and receive control messages and/or data messages fromanother radio network controller, such as radio network controller124-2. Other interfaces 440 may include interfaces to other devicesand/or networks. For example, other interfaces 440 may include an lucsinterface, which is a core network interface to a circuit-switched voicenetwork, and an lups interface, which is a core network interface to apacket-switched data network.

In some embodiments, one or more components of radio network controller124-1 may perform the tasks described as being performed by one or moreother components of radio network controller 124-1.

FIG. 5 is a flowchart of an exemplary process for transmitting a dataframe according to an exemplary embodiment. In one embodiment, portionsof the process described in FIG. 5 may be performed by a base station,such as base station 122-1, and a portion of the process may beperformed by a radio network controller, such as radio networkcontroller 124-1. In another embodiment, some or all of the exemplaryprocess described below may be performed by another device orcombination of devices.

The exemplary process may begin with base station 122-1 generating aHS-DSCH framing protocol type 2 CAPACITY ALLOCATION Control Frame (block505). In one embodiment, base station 122-1 may generate the HS-DSCHframing protocol type 2 CAPACITY ALLOCATION Control Frame in response toa HS-DSCH Capacity Request from radio network controller 124-1 or at anyother time. Among other things, the HS-DSCH framing protocol type 2CAPACITY ALLOCATION Control Frame may specify MAC-d PDU credits inoctets, rather than by a number of PDUs.

FIG. 6 is an exemplary diagram of a HS-DSCH framing protocol type 2CAPACITY ALLOCATION Control Frame 600 according to an exemplaryembodiment. As illustrated, HS-DSCH framing protocol type 2 CAPACITYALLOCATION Control Frame 600 may include a Congestion Status informationelement 610, a Common Transport Channel Priority Indicator (CmCH-PI)information element 620, MAC-d PDU Credits information element 630, aHS-DSCH Interval information element 640, a HS-DSCH Repetition Periodinformation element 650, and a Spare Extension information element 660.In other embodiments, HS-DSCH framing protocol type 2 CAPACITYALLOCATION Control Frame 600 may maintain additional or differentinformation elements than the information elements illustrated in FIG.6.

Congestion Status information element 610 may include information thatindicates whether a congestion situation has been detected. CommonTransport Channel Priority Indicator information element 620 may includeinformation that indicates the relative priority of the data frame to betransferred from radio network controller 124-1. MAC-d PDU Creditsinformation element 630 may include information indicating the number ofMAC-d PDUs octets that a radio network controller may transmit duringone HS-DSCH interval granted by HS-DSCH framing protocol type 2 CAPACITYALLOCATION Control Frame 600. In one embodiment, the value for MAC-d PDUCredits information element may range, e.g., from 0 to 16,777,215, where“0” may represent stop transmission, and “16,777,215” may represent anunlimited transmission. The field length of MAC-d PDU Creditsinformation element may be 24 bits.

In an alternative embodiment, MAC-d PDU Credits information element 630may be 20 bits, where three of the remaining four bits may be used asspare bits and one bit may be used to indicate whether or not unusedcredit octets may be reused by radio network controller 124-1 in thenext interval.

HS-DSCH Interval information element 640 may store informationrepresenting a time interval during which the HS-DSCH Credits granted inHS-DSCH framing protocol type 2 CAPACITY ALLOCATION Control Frame 600may be used. HS-DSCH Repetition Period information element 650 may storeinformation that represents the number of subsequent intervals that theHS-DSCH Credits in HS-DSCH framing protocol type 2 CAPACITY ALLOCATIONControl Frame 600 may be used. Spare Extension information element 660may be a placeholder for future information elements that may be addedto HS-DSCH framing protocol type 2 CAPACITY ALLOCATION Control Frame600.

Thus, according to one exemplary embodiment, a new “MAC-d PDU Credits”information element 630 is introduced into a HS-DSCH CAPACITY ALLOCATIONControl Frame, which replaces the old “HS-DSCH Credits” field. WithMAC-d PDU Credits information element 630 having octet granularity (notnumber of PDUs), situations may arise where at the end of a HS-DSCHinterval, one or more octets cannot be used for sending MAC-d PDUs(e.g., because the amount of remaining octets is less than the length ofthe waiting MAC-d PDU). If HS-DSCH Repetition Period information element650 indicates that the repetition period is larger than 1 or is zero,the “MAC-d PDU Credits” may be granted to the transport network flow inevery HS-DSCH interval. In this situation, the radio network controllermay reuse these unused credits at the beginning of the next HS-DSCHinterval.

Returning to FIG. 5, base station 122-1 may transfer the HS-DSCH framingprotocol type 2 CAPACITY ALLOCATION Control Frame (e.g., HS-DSCH framingprotocol type 2 CAPACITY ALLOCATION Control Frame 600) to radio networkcontroller 124-1 (block 510). For example, base station 122-1 maytransfer the HS-DSCH framing protocol type 2 CAPACITY ALLOCATION ControlFrame to radio network controller 124-1 via lub interface 240.

Radio network controller 124-1 may receive the HS-DSCH framing protocoltype 2 CAPACITY ALLOCATION Control Frame (block 515). For example, radionetwork controller 124-1 may receive the HS-DSCH framing protocol type 2CAPACITY ALLOCATION Control Frame via lub interface 420. In response toreceiving the HS-DSCH framing protocol type 2 CAPACITY ALLOCATIONControl Frame, radio network controller 124-1 may generate a HS-DSCHframing protocol type 2 DATA FRAME (block 520). Among other things, theHS-DSCH framing protocol type 2 DATA FRAME may store blocks of PDUs ofthe same length, where the PDUs of one block may differ in length fromPDUs of another block.

FIG. 7A is an exemplary diagram of a HS-DSCH framing protocol type 2DATA FRAME 700 according to an exemplary embodiment. As illustrated,HS-DSCH framing protocol type 2 DATA FRAME 700 may include a header 701and a payload 715. Header 701 may include a Header Cyclic RedundancyChecksum (CRC) information element 702, a Frame Type (FT) informationelement 703, a Frame Sequence (Seq.) Number information element 704, aCommon Transport Channel Priority Indicator (CmCH-PI) informationelement 705, a Flush information element 706, a Logical (Log.) Channel(ch.) Identifier (ID) information element 707, a User Buffer Sizeinformation element 708, a Total Number of PDU Blocks informationelement 709, and a number (#) of PDU block description informationelements 710 (e.g., where each block is associated with a MAC-d PDULength in Block information element 711 and a number of PDUs (#PDUs) inBlock information element 712). In other embodiments, header 701 mayinclude additional and/or different information elements than depictedin FIG. 7A.

Header CRC information element 702 may store a CRC calculated on header701 of DATA FRAME 700. Frame Type information element 703 may storeinformation indicating whether frame 700 is a data frame or a controlframe. Frame Sequence Number information element 704 may store a valuerepresenting the frame sequence number for DATA FRAME 700 in a MAC-dflow. Common Transport Channel Priority Indicator information element705 may include information that indicates the relative priority of DATAFRAME 700. Flush information element 706 may store information thatindicates whether the DRNC should or should not remove all the MAC-dPDUs form the corresponding priority queue that have been received priorto DATA FRAME 700 on the same transport bearer. Logical ChannelIdentifier information element 707 may store information identifying alogical channel instance when multiple logical channels are carried onthe same transport network flow. In one embodiment, Logical ChannelIdentifier information element 707 may store, for example, a valuebetween 0 and 15, where the values 0 to 14 may identify Logical channels1-15, and the value 15 may be reserved for future use. The field lengthof Logical Channel Identifier information element 707 may be four bitsin one exemplary embodiment. User Buffer Size information element 708may store information representing the buffer size (e.g., the amount ofdata in the buffer) in octets for a given Common Transport ChannelPriority Indicator level.

Total Number of PDU Blocks information element 709 may store informationrepresenting the total number of PDU blocks in DATA FRAME 700. A PDUblock may be defined as one or more PDUs of the same length. Each PDUblock may be described by the length of PDUs and the number of PDUs inthe block. In situations where in-order delivery is desirable, more thanone block with PDUs of the same length may be included in DATA FRAME700. For example, if the maximum PDU length is significantly smallerthan a full IP packet, the IP packet may be segmented in many PDUs insequence, each with the same maximum PDU length. In one embodiment, aPDU block may support PDU lengths that are as long as an IP packet(e.g., 1,500 octets). Total Number of PDU Blocks information element 709may store, for example, a value between 0 and 31, where the value “0”may represent an invalid value. The field length of Total Number of PDUBlocks information element 709 may be five bits in one exemplaryembodiment.

As indicated above, each PDU block in DATA FRAME 700 may be associatedwith PDU block description information elements 710. PDU blockdescription information elements 710 may include a MAC-d PDU Length inBlock information element 711 and a Number (#) of PDUs in Blockinformation element 712. MAC-d PDU Length in Block information element711 may store information representing the length of every MAC-d PDU inthat particular block. The length may be provided in octets. In oneembodiment, MAC-d PDU Length in Block information element 711 may store,for example, a value between 0 and 2,047, where the value “0” mayrepresent an invalid value. The field length of MAC-d PDU Length inBlock information element 711 may be eleven bits in one exemplaryembodiment. Number of PDUs in Block information element 712 may storeinformation representing a quantity of MAC-d PDUs in the particularblock. In one embodiment, Number of PDUs in Block information element712 may store, for example, a value between 0 and 31, where the value“0” may represent an invalid value. The field length of Number of PDUsin Block information element 712 may be five bits in one exemplaryembodiment.

Payload 715 may include one or more blocks of PDUs 716, a NewInformation Element (IE) Flags information element 717, a DelayReference Time (DRT) information element 718, a Spare Extensioninformation element 719, and a Payload CRC information element 720. Inother embodiments, payload 715 may include additional and/or differentinformation elements than depicted in FIG. 7A.

The order of PDU blocks 716 in payload 715 may follow a correspondingorder of the PDU block description information elements in header 701.In the exemplary configuration illustrated in FIG. 7A, header 701includes descriptions for PDU blocks 1 to n. Thus, payload 715 mayinclude n PDU blocks, ordered from 1 to n. As indicated above, each PDUblock may include one or more PDUs of the same length. However, thelength of PDUs in one block may differ from the length of PDUs inanother block in payload 715.

New Information Element Flags information element 717 may storeinformation (e.g., one or more flags) if at least one new informationelement is present in DATA FRAME 700. Each flag may indicate which newinformation elements are present following New Information Element Flagsinformation element 717. Delay Reference Time information element 718may store information used for dynamic delay measurements. SpareExtension information element 719 may be a placeholder for futureinformation elements that may be added to DATA FRAME 700. Payload CRCinformation element 720 may store a CRC calculated on payload 715 ofDATA FRAME 700.

As an alternative to the exemplary configuration illustrated in FIG. 7A,the MAC-d PDU Length in Block information element may be increased byone bit to be able to support 4-bit MAC-d PDU length granularity. Thisalternative embodiment may support legacy user equipment with MAC-dmultiplexing enabled. If the removal of MAC-d multiplexing is notaccepted in a radio access network, the length of the MAC-d PDU Lengthin Block information element may be increased to express the length in4-bit units and the Logical Channel Identifier information element maybe removed.

In some situations (e.g., when a DATA FRAME includes small PDUs ofdifferent length), a 1-bit “More Information” information element may beincluded in PDU block description information elements 710 in header701. An exemplary diagram of alternative PDU description informationelements 725 for this alternative embodiment is depicted in FIG. 7B. Asillustrated, the MAC-d PDU Length in Block information element and theNumber (#) of PDUs in Block information element from DATA FRAME 700 aresupplemented with a “More Information” (MI) information element 726,which may store information relating to the PDUs in the block. In oneembodiment, if the “More Information” information element 726 stores avalue of 0, the associated MAC-d PDU Length in Block information elementmay be seven bits long and the number of PDUs in the given block maybe 1. If, on the other hand, the “More Information” information element726 stores a value of 1, four bits of the next octet may also indicatelength (13 bits in total) and the other four bits may indicate thenumber of PDUs.

FIG. 7C is an exemplary alternative diagram of a HS-DSCH framingprotocol type 2 DATA FRAME 730 according to an exemplary embodiment. Inthis embodiment, PDU description information elements 710 (i.e., MAC-dPDU Length in Block information element 711 and Number of PDUs in Blockinformation element 712) for each block are distributed in payload 715,instead of header 701 (as in DATA FRAME 700). As illustrated, PDUdescription information element 710 for a given block may be placedright before PDUs 716 for that block.

In another embodiment, a length indicator (e.g., a 12-bit indicator) foreach MAC-d PDU may be included in the header or payload of a HS-DSCHframing protocol type 2 DATA FRAME. An exemplary HS-DSCH framingprotocol type 2 DATA FRAME 735 with length indictors in a header portion740 is illustrated in FIG. 7D. As shown, header 740 of HS-DSCH framingprotocol type 2 DATA FRAME 735 may include a Header Cyclic RedundancyChecksum (CRC) information element 702, a Frame Type (FT) informationelement 703, a Frame Sequence (Seq.) Number information element 704, aCommon Transport Channel Priority Indicator (CmCH-PI) informationelement 705, a Flush information element 706, a Logical (Log.) Channel(ch.) Identifier (ID) information element 707, a User Buffer Sizeinformation element 708, a Total Number of PDUs information element 741,and a number of MAC-d PDU Length Indicator information elements 742(e.g., one for each PDU in DATA FRAME 735). In other embodiments, header740 may include additional and/or different information elements thanthe information elements depicted in FIG. 7D.

Header Cyclic Redundancy Checksum information element 702, Frame Typeinformation element 703, Frame Sequence Number information element 704,Common Transport Channel Priority Indicator information element 705,Flush information element 706, Logical Channel Identifier informationelement 707, and User Buffer Size information element 708 may includeinformation similar to that described above with respect to FIG. 7A.Total Number of PDUs information element 741 may store informationrepresenting a number (or quantity) of PDUs in DATA FRAME 735. EachMAC-d PDU Length Indicator information element 742 may store informationrepresenting the length (e.g., in octets) of the corresponding PDU inpayload 745. For example, if the PDU #1 has a length of 8 octets, theMAC-d PDU Length Indicator information element for PDU #1 may store avalue indicating 8 octets.

Payload 745 may include one or more PDUs 746, a New Information Element(IE) Flags information element 717, a Delay Reference Time (DRT)information element 718, a Spare Extension information element 719, anda Payload CRC information element 720. In other embodiments, payload 745may include additional and/or different information elements thandepicted in FIG. 7D.

In payload 745, each PDU may be placed in its original order to avoidreordering. The order of the PDUs may correspond to the order of MAC-dPDU Length Indicators 742 in header 740. New Information Element Flagsinformation element 717, Delay Reference Time information element 718,Spare Extension information element 719, and Payload CRC informationelement 720 may include information similar to that described above withrespect to FIG. 7A.

In some embodiments, the logical channel identifier may be the same foran entire HS-DSCH framing protocol type 2 DATA FRAME, such as DATA FRAME700 in FIG. 7A. In other embodiments, a particular HS-DSCH framingprotocol type 2 DATA FRAME may be associated with more than one logicalchannel identifier. FIG. 7E is an exemplary diagram of a HS-DSCH framingprotocol type 2 DATA FRAME 750 that is associated with more than onelogical channel identifier. As shown, header 755 of HS-DSCH framingprotocol type 2 DATA FRAME 750 may include a Header Cyclic RedundancyChecksum (CRC) information element 702, a Frame Type (FT) informationelement 703, a Frame Sequence (Seq.) Number information element 704, aCommon Transport Channel Priority Indicator (CmCH-PI) informationelement 705, a Flush information element 706, a User Buffer Sizeinformation element 708, a Total Number of PDU Blocks informationelement 709, and a number of MAC-d PDU description information elements751 (e.g., one for each PDU in DATA FRAME 750), where MAC-d PDUdescription information elements 751 for a particular PDU includes aLogical Channel Identifier for PDU information element 752 and a MAC-dPDU Length Indicator information element 753. In other embodiments,header 755 may include additional and/or different information elementsthan depicted in FIG. 7E.

Header Cyclic Redundancy Checksum information element 702, Frame Typeinformation element 703, Frame Sequence Number information element 704,Common Transport Channel Priority Indicator information element 705,Flush information element 706, User Buffer Size information element 708,and Total Number of PDU Blocks information element 709 may includeinformation similar to that described above with respect to FIG. 7A.Logical Channel Identifier for PDU information element 752 may storeinformation identifying a logical channel instance for the PDU. In oneembodiment, Logical Channel Identifier information element 752 maystore, for example, a value between 0 and 15, where the values 0 to 14may identify Logical channels 1-15, and the value “15” may be reservedfor future use. The field length of Logical Channel Identifierinformation element 752 may be four bits in one exemplary embodiment.MAC-d PDU Length Indicator information element 753 for a PDU may storeinformation representing the length (e.g., in octets) of thecorresponding PDU in payload 760. For example, if the PDU #1 has alength of 8 octets, MAC-d PDU Length Indicator information element 753for PDU #1 may store a value indicating 8 octets.

Payload 760 may include one or more PDUs 761, a New Information Element(IE) Flags information element 717, a Delay Reference Time (DRT)information element 718, a Spare Extension information element 719, anda Payload CRC information element 720. In other embodiments, payload 760may include additional and/or different information elements thandepicted in FIG. 7E.

In payload 760, each PDU may be placed in its original order to avoidreordering. The order of PDUs 716 may correspond to the order of MAC-dPDU Length Indicators 753 in header 755. New Information Element Flagsinformation element 717, Delay Reference Time information element 718,Spare Extension information element 719, and Payload CRC informationelement 720 may include information similar to that described above withrespect to FIG. 7A.

Returning to FIG. 5, radio network controller 124-1 may transfer theHS-DSCH framing protocol type 2 DATA FRAME (e.g., DATA FRAME 700, 730,735, or 750) to base station 122-1 (block 525). For example, radionetwork controller 124-1 may transfer the HS-DSCH framing protocol type2 DATA FRAME to base station 122-1 via lub interface 420.

Base station 122-1 may receive the HS-DSCH framing protocol type 2 DATAFRAME from radio network controller 124-1 (block 530). For example, basestation 122-1 may receive the HS-DSCH framing protocol type 2 DATA FRAMEvia lub 240. Base station 122-1 may parse the HS-DSCH framing protocoltype 2 DATA FRAME to extract the logical channel identifier(s) from theHS-DSCH framing protocol type 2 DATA FRAME (e.g., from Logical ChannelIdentifier information element 707 in header 701 of HS-DSCH framingprotocol type 2 DATA FRAME 700) and map the extracted logical channelidentifier(s) to priority queue identifier(s) (block 535). For example,base station 122-1 may, via, for example, logical channel identifier topriority queue mapper 236, use an extracted logical channel identifierto lookup (e.g., via computer-readable medium 300) an identifier for apriority queue of priority queues 234 for the PDUs of the DATA FRAME. Inthe situation where the HS-DSCH framing protocol type 2 DATA FRAMEincludes multiple logical channel identifiers (e.g., DATA FRAME 750 inFIG. 7E), base station 122-1 may perform multiple lookup operations toidentify priority queues for the PDUs associated with the logicalchannel identifiers.

In the prior art, a High Speed Downlink Packet Access (HSDPA) basestation maintains a number of priority queues. An instance of a priorityqueue is initialized when a MAC-d flow is established via Node BApplication Part (NBAP) messages. Furthermore, one priority queue mayserve several logical channels (or radio bearers). The prior art doesnot include signaling to the base station to support a mapping ofpriority queue to the logical channel (or Radio Bearer) that use theHSDPA Radio Link/Radio Bearer for user data transport. The consequenceof this is that the priority queue identifier is transported togetherwith the logical channel for each PDU to the user equipment so that theuser equipment is able to determine 1) to which logical channel a PDUbelongs; and 2) which priority queue was used for the scheduling andreordering. This leads to unnecessarily large overhead over the radiointerface.

In stark contrast, in embodiments described herein, the radio networkcontroller may transmit control messages to the base station thatprovide a mapping between the logical channel and the priority queue.This mapping is already included in the prior art when it comes tosignaling between the controlling radio network controller/serving radionetwork controller (CRNC/SRNC) and the user equipment. By signaling thesame mapping to the base station, only identification of the logicalchannel has to be added to each PDU sent to the user equipment from thebase station. The user equipment may then be able to determine thecorrect priority queue identifier from the logical channel identifier.Thus, overhead in the radio interface may be decreased.

Table 1 shows examples of overhead values relating to an old HS-DSCHDATA FRAME format (i.e., the HS-DSCH framing protocol type 1 DATA FRAME)and a new HS-DSCH DATA FRAME format (i.e., the HS-DSCH framing protocoltype 2 DATA FRAME according to the exemplary embodiments describedhere). The examples assume that the Delay Reference Time informationelement is not present in the DATA FRAMES. As illustrated, the newHS-DSCH DATA FRAME format saves considerable overhead in every situation(except where a single PDU of 10 octets is sent—in that situation, theoverhead would be equal).

TABLE 1 Overhead - new Example case Overhead - old format format 10 PDUsof length 42 19 octets 10 octets octets (case of a legacy (7 header, 2CRC, 10 (6 header, 1 * 2 block UE) spare + Pad) header, 2 CRC) 2 PDUs of500 octets 1 21 octets 12 octets PDU of 400 octets (2 * 7 header, 2 * 2(6 header, 2 * 2 block CRC, 3 spare + Pad - header, 2 CRC) sent in twoframes) 1 PDU of 10 octets 10 octets 10 octets (7 header, 2 CRC, 1 (6header, 1 * 2 block spare + Pad) header, 2 CRC) 1 PDU of 1500 octets Notsupported 10 octets (6 header, 1 * 2 block header, 2 CRC)

Once the priority queue(s) have been identified, base station 122-1 maystore the PDUs from the HS-DSCH framing protocol type 2 DATA FRAME intothe appropriate priority queue(s) in priority queues 234 for latertransmission to a user equipment 110 (block 540).

Returning to block 525, once radio network controller 124-1 sends theHS-DSCH framing protocol type 2 DATA FRAME, radio network controller124-1 may determine whether unused credits remain from the HS-DSCHframing protocol type 2 CAPACITY ALLOCATION Control Frame (block 545).As indicated above, the MAC-d PDU Credits information element of theHS-DSCH framing protocol type 2 CAPACITY ALLOCATION Control Frameindicates the number of MAC-d PDUs octets that a radio networkcontroller is allowed to transmit during one HS-DSCH interval granted inthe HS-DSCH framing protocol type 2 CAPACITY ALLOCATION Control Frame(e.g., in MAC-d PDU Credits information element 630). If the CapacityAllocation Control Frame is valid for more than one interval, the radionetwork controller may reuse credits that were not used within a certaininterval in the subsequent interval.

If radio network controller 124-1 determines that unused credits remainfrom the HS-DSCH framing protocol type 2 CAPACITY ALLOCATION ControlFrame (block 545—YES), radio network controller 124-1 may use the unusedcredits in the next interval (block 550). In one embodiment, radionetwork controller 124-1 may use the unused credits in only the nextinterval (and not intervals beyond the next interval). The ability touse credits, which were not used in a previous interval, in the nextinterval provides for a stable bitrate. If, on the other hand, radiolink controller 124-1 determines that no unused credits remain from theHS-DSCH framing protocol type 2 CAPACITY ALLOCATION Control Frame (block545—NO), processing may end. For example, processing may return to block515 with radio network controller 124-1 receiving another HS-DSCHframing protocol type 2 CAPACITY ALLOCATION Control Frame.

FIG. 8 is a flowchart of an exemplary process for determining whether anode is capable of supporting the HS-DSCH framing protocol type 2 formataccording to an exemplary embodiment. In one embodiment, portions of theprocess described in FIG. 8 may be performed by a base station, such asbase station 122-1, and a portion of the process may be performed by aradio network controller, such as radio network controller 124-1. Inanother embodiment, some or all of the exemplary process described belowmay be performed by another device or combination of devices. Forexample, the process described below may be performed by first andsecond radio network controllers.

The exemplary process may begin with radio network controller 124-1generating a control message that identifies the HS-DSCH framingprotocol type supported (block 805). In one embodiment, the controlmessage may include, for example, a RADIO LINK SETUP REQUEST message, aRADIO LINK ADDITION REQUEST message, a RADIO LINK RECONFIGURATIONREQUEST message, a RADIO LINK RECONFIGURATION PREPARATION REQUESTmessage, a PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message,and/or another type of control message. In one embodiment, the controlmessage may include a HS-DSCH Framing Protocol Type Support informationelement in the Information Element HS-DSCH Frequency Division Duplex(FDD) Information. The exemplary coding of the HS-DSCH Framing ProtocolType Support information element is presented in Table 2. Asillustrated, the HS-DSCH Framing Protocol Support information elementmay, in one exemplary embodiment, store an 8-bit Boolean list. OtherBoolean list sizes are possible. The HS-DSCH Framing Protocol Supportinformation element may indicate which HS-DSCH framing protocol typesare supported. More than one framing protocol type may be supported.From the right to the left of the Boolean list, each position mayindicate a HS-DSCH framing protocol type 1 to 8. In one embodiment, a“0” may indicate that the type is not supported and a “1” may indicatethe type is supported. For example, a Boolean list of “11000000” mayindicate that both type 1 and type 2 framing protocol formats aresupported.

TABLE 2 IE Type and IE/Group Name Presence Range Reference HS-DSCHFraming BOOLEAN Protocol Type Support LIST (SIZE(8))

Radio network controller 124-1 may send the control message to basestation 122-1 (block 810). For example, radio network controller 124-1may send the control message via lub interface 420. Base station 122-1may receive the control message (block 815). For example, base station122-1 may receive the control message via lub interface 240. Uponreceipt of the control message (which includes the HS-DSCH FramingProtocol Type information element), base station 122-1 may select aHS-DSCH framing protocol type (block 820). Base station 122-1 may makethe selection based on a number of factors. For example, in oneembodiment, base station 122-1 may select the HS-DSCH framing protocoltype 2 whenever base station 122-1 is compatible with that framingprotocol format. Otherwise, base station 122-1 may select the HS-DSCHframing protocol type 1.

Base station 122-1 may generate a response message that identifies theselected HS-DSCH framing protocol type (block 825). In one embodiment,the response message may include, for example, a RADIO LINK SETUPRESPONSE message, a RADIO LINK ADDITION RESPONSE message, a RADIO LINKRECONFIGURATION RESPONSE message, a RADIO LINK RECONFIGURATIONPREPARATION RESPONSE message, a PHYSICAL SHARED CHANNEL RECONFIGURATIONRESPONSE message, and/or another type of response message. The type ofresponse message generated may be based on the control message receivedfrom radio network controller 124-1. In one embodiment, the responsemessage may include a HS-DSCH Framing Protocol Type Selected informationelement in the Information Element HS-DSCH Frequency Division Duplex(FDD) Information Response. The exemplary coding of the HS-DSCH FramingProtocol Type Selected information element is presented in Table 3. Asillustrated, the HS-DSCH Framing Protocol Selected information elementmay, in one exemplary embodiment, store an integer (e.g., from 1 to 8)that represents the protocol type number. The HS-DSCH Framing ProtocolSelected information element may indicate the HS-DSCH Framing ProtocolType to be used. For example, a value of “1” may indicate that theHS-DSCH framing protocol type 1 has been selected and a value of “2” mayindicate that the HS-DSCH framing protocol type 2 has been selected.

TABLE 3 IE Type and IE/Group Name Presence Range Reference HS-DSCHFraming INTEGER Protocol Type Selected (1 . . . 8)

In one embodiment, base station 122-1 may include a HS-DSCH InitialCapacity Allocation information element in the response message. TheHS-DSCH Initial Capacity Allocation information element may provide flowcontrol information for each scheduling priority class for the HS-DSCHframing protocol over the lub interface. The HS-DSCH Initial CapacityAllocation information element may include a Scheduling Indicatorinformation element (which may store information representing therelative priority of the HS-DSCH DATA FRAME), a Maximum MAC-d PDU Sizeinformation element (which may store information representing the length(e.g., in bits) of the MAC-d PDU), and a HS-DSCH Initial Window Sizeinformation element (which may store information representing theinitial number of MAC-d PDUs that may be transmitted by radio networkcontroller 124-1 before new credits are received from base station122-1). The interpretation of the HS-DSCH Initial Capacity Allocationinformation element may vary based on the framing protocol typeselected. For example, for the framing protocol type 2, the HS-DSCHInitial Capacity Allocation information element may be interpreted bymultiplying the maximum MAC-d PDU length (Maximum MAC-d PDU Size) by thenumber of MAC-d PDUs (HS-DSCH Initial Window Size). This gives a totalnumber of bits (or octets).

In one embodiment, base station 122-1 may include a Maximum HS-DSCHFraming Protocol DATA FRAME Length information element in theInformation Element HS-DSCH Frequency Division Duplex (FDD) InformationResponse (block 830). The exemplary coding of the HS-DSCH FramingProtocol DATA FRAME Length information element is presented in Table 4.As illustrated, the HS-DSCH Framing Protocol DATA FRAME Lengthinformation element may, in one exemplary embodiment, store an integer(e.g., from 1 to 5,000 or higher) that represents the maximum HS-DSCHFraming Protocol DATA FRAME length in octets. In practice, when radionetwork controller 124-1 has a receiving Framing Protocol MaximumTransmission Unit that has a length that is equal to the maximum lengthin the HS-DSCH Framing Protocol DATA FRAME Length information element,radio network controller 124-1 may take its own Framing Protocol MaximumTransmission Unit into account and trigger the Radio Link Controlmaximum PDU length accordingly. This information element may beapplicable to all HS-DSCH framing protocol types.

TABLE 4 IE Type and IE/Group Name Presence Range Reference MaximumHS-DSCH INTEGER Framing Protocol DATA (1, . . . , 5000, . . . ) FRAMELength

Once the response message has been generated, base station 122-1 maysend the response message to radio network controller 124-1 (block 835).For example, base station 122-1 may send the control message via lubinterface 240. Radio network controller 124-1 may receive the controlmessage (block 840). For example, radio network controller 124-1 mayreceive the control message via lub interface 420. Radio networkcontroller 124-1 may determine whether a framing protocol type has beenselected by base station 122-1 (block 845). For example, radio networkcontroller 124-1 may parse the response message to determine whether theresponse message includes the HS-DSCH Framing Protocol Type Selectedinformation element.

If the HS-DSCH Framing Protocol Type Selected information element isincluded in the received response message (block 845—YES), radio networkcontroller 124-1 may identify the HS-DSCH framing protocol type selectedby base station 122-1 based on that information element. Radio networkcontroller 124-1 may generate HS-DSCH DATA FRAMES to base station 122-1according to the selected HS-DSCH framing protocol type selected (block850). For example, if the HS-DSCH Framing Protocol Type Selectedinformation element indicates that base station 122-1 selected theHS-DSCH framing protocol type 2 format, radio network controller 124-1may generate and send HS-DSCH framing protocol type 2 DATA FRAMES tobase station 122-1.

If, on the other hand, the HS-DSCH Framing Protocol Type Selectedinformation element is not included in the received response message(or, for example, no response is received from base station 122-1)(block 845—NO), radio network controller 124-1 may generate and sendHS-DSCH DATA FRAMES to base station 122-1 based on a predeterminedHS-DSCH framing protocol type (block 855). In one embodiment, thepredetermined HS-DSCH framing protocol type may include the HS-DSCHframing protocol type 1 format.

As an alternative to the process described above with respect to FIG. 8,the capabilities of a base station to handle different HS-DSCH framingprotocol types may be configured in the radio network controller withwhich the base station is associated. For example, radio networkcontroller 124-1 may be configured with information identifying theHS-DSCH framing protocol types supported by base stations 122-1 and122-2. Thus, when, for example, radio network controller 124-1 has PDUsto send to base station 122-1, radio network controller 124-1 maydetermine whether base station 122-1 is capable of handling the HS-DSCHframing protocol type 2 (e.g., by looking up the information in a memoryassociated with radio network controller 124-1). When base station 122-1is capable of handling the HS-DSCH framing protocol type 2, radionetwork controller 124-1 may generate a HS-DSCH framing protocol type 2DATA FRAME, as described herein, that includes the PDUs and may transferthe DATA FRAME to base station 122-1.

In one embodiment 900 illustrated in FIG. 9, a serving radio networkcontroller (SRNC) may need to know whether a drift radio networkcontroller (DRNC) supports flexible PDU length (i.e., the HS-DSCHframing protocol type 2 format). This support may differ from cell tocell, as not all base stations associated with the drift radio networkcontroller may support new flexible PDU length DATA FRAMES. The solutionfor this is to include information about support for flexible PDU lengthfor each cell in a CAPABILITY CONTAINER information element 910 sentfrom the drift radio network controller to the serving radio networkcontroller. Similarly, for serving radio network controller relocations,an information element may be included in a SOURCE RNC TO TARGET RNCTRANSPARENT CONTAINER that is transmitted from a relocating servingradio network controller to a target radio network controller, whichconveys the capability to handle flexible PDU length DATA FRAMES.

The ability to support flexible PDU length DATA FRAMES may also beconveyed to user equipment 110. For example, an information element maybe included in a control message to user equipment 110 that indicateswhether or not the base station can support flexible PDU length DATAFRAMES. The control message may include, for example, a RADIO BEARERSETUP message, a RADIO BEARER RECONFIGURATION message, a TRANSPORTCHANNEL RECONFIGURATION message, and/or another type of control message.

Thus, as described herein, the HS-DSCH framing protocol type 2 frameformats may provide:

-   -   a maximum MAC-d PDU length of ˜1500 octets and octet granularity        in MAC-d PDU length is efficiently supported;    -   ability to take into account the Maximum Transmission Unit        limitation of the used transport network;    -   ability to support flexible MAC-d (RLC) PDU lengths;    -   ability to support higher High Speed Packet Access (HSPA)        Evolution bitrates (e.g., up to ˜42 Megabits per second (Mbps));    -   small Transport Network Layer overhead (data frame header and        control frame length); and    -   single data frame and control frame format for Release 7, making        for easier expansion in the future.

The HS-DSCH framing protocol type 2 CAPACITY ALLOCATION Control Framemay provide:

-   -   ability to represent octets or bitrate (instead of number of        PDUs and Maximum PDU length);    -   ability to have a good bitrate granularity; and    -   Ability to send large or small PDUs with small latency and not        too bursty load on the Transport Network.

The HS-DSCH framing protocol type 2 DATA FRAME may provide:

-   -   ability to support flexible MAC-d PDU lengths;    -   small overhead for all cases, e.g. PDUs of different length in        the same data frame; and    -   small PDUs of the same length.

The embodiments described herein provide an efficient solution for thetransport network support for flexible PDU length DATA FRAMES. TheHS-DSCH framing protocol type 2 CAPACITY ALLOCATION Control Framesupports larger MAC-d PDU lengths by allowing the reuse of unusedcredits. The HS-DSCH framing protocol type 2 DATA FRAME allows largeMAC-d PDU lengths, and more than one PDU length in the same data frame.Also, the HS-DSCH framing protocol type 2 DATA FRAME allows MAC-d PDUsfrom several logical channels within one connection. The header overheadand padding for the transport network are kept small for typical usagescenarios.

The new information elements described herein allow improvedinteroperability between different frame formats without adding newsignaling messages. The new interpretation of the HS-DSCH INITIALCAPACITY ALLOCATION information element supports flexible PDU lengthDATA FAMES without changing the definition of the information element.

Embodiments described herein provide illustration and description, butis not intended to be exhaustive or to limit the implementations to theprecise form disclosed. Modifications and variations are possible inlight of the above teachings, or may be acquired from practice of theimplementations. For example, while the following description focuses onthe Universal Mobile Telecommunications System (UMTS) Terrestrial RadioAccess Network (UTRAN) architecture, it will be appreciated that thetechniques described herein are equally applicable to other types ofarchitectures, such as the UTRAN flat architecture. In the UTRAN flatarchitecture, the radio network controller (RNC) and the base station(BS) may be combined into a single RNC/BS node. A gateway device maytransfer traffic between the core network and the RNC/BS node via thetransport network.

While series of acts have been described with regard to FIGS. 5 and 8,the order of the acts may be modified in other embodiments. Further,non-dependent acts may be performed in parallel.

The exemplary embodiments, as described above, may be implemented inmany different forms of software, firmware, and hardware in theimplementations illustrated in the figures. The actual software code orspecialized control hardware used to implement the exemplary embodimentsdescribed herein is not limiting of the present disclosure. Thus, theoperation and behavior of the exemplary embodiments were describedwithout reference to the specific software code—it being understood thatone would be able to design software and control hardware to implementthe exemplary embodiments based on the description herein.

Further, certain portions of the present disclosure may be implementedas “logic” that performs one or more functions. This logic may includehardware, such as an application specific integrated circuit, a fieldprogrammable gate array, a processor, or a microprocessor, software, ora combination of hardware and software.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the present disclosure. In fact, many of thesefeatures may be combined in ways not specifically recited in the claimsand/or disclosed in the specification.

It should be emphasized that the term “comprises/comprising” when usedin the this specification is taken to specify the presence of statedfeatures, integers, steps, or components, but does not preclude thepresence or addition of one or more other features, integers, steps,components, or groups thereof.

No element, act, or instruction used in the description of the presentapplication should be construed as critical or essential to the presentdisclosure unless explicitly described as such. Also, as used herein,the article “a” is intended to include one or more items. Where only oneitem is intended, the term “one” or similar language is used. Further,the phrase “based on” is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

Thus, the foregoing description and the accompanying drawings representnon-limiting examples of the methods and apparatus taught herein. Assuch, the present disclosure is not limited by the foregoing descriptionand accompanying drawings. Instead, the present disclosure is limitedonly by the following claims and their legal equivalents.

What is claimed is:
 1. A method performed by a first device in a HighSpeed Downlink Packet Access environment, the method comprising:generating a High Speed Downlink Shared Channel Capacity Allocationcontrol frame that includes a value representing a number of packet dataunit octets that a second device is permitted to transmit during a HighSpeed Downlink Shared Channel interval; and transferring the High SpeedDownlink Shared Channel Capacity Allocation control frame to the seconddevice.
 2. The method of claim 1, wherein the High Speed Downlink SharedChannel Capacity Allocation control frame further includes a firstinformation element that stores a time interval during which the seconddevice is permitted to use the number of packet data unit octets.
 3. Themethod of claim 2, wherein the High Speed Downlink Shared Channelcapacity Allocation control frame further includes a second informationelement that stores a value indicating a number of subsequent intervalsduring which the second device is permitted to use the number of packetdata unit octets.
 4. A device comprising: a processing circuitconfigured to generate a High Speed Downlink Shared Channel capacityAllocation control frame that includes a value representing a number ofpacket data unit octets that a radio network controller is permitted totransmit during a High Speed Downlink Shared Channel interval; and anlub interface configured to transfer the High Speed Downlink SharedChannel Capacity Allocation control frame to the radio networkcontroller.
 5. The device of claim 4, wherein the High Speed DownlinkShared Channel Capacity Allocation control frame further includes: afirst information element that stores a time interval during which theradio network controller is permitted to use the number of packet dataunit octets; and a second information element that stores a valueindicating a number of subsequent intervals during which the radionetwork controller is permitted to use the number of packet data unitoctets.
 6. A method performed by a first device in a High Speed DownlinkPacket Access environment, the method comprising: receiving a High SpeedDownlink Shared Channel capacity Allocation control frame from a seconddevice, the High Speed Downlink Shared Channel Capacity Allocationcontrol frame including a first value representing a first number ofpacket data unit octets that the first device is permitted to transmitduring a High Speed Downlink Shared Channel interval; generating, inresponse to receiving the High Speed Downlink Shared Channel CapacityAllocation control frame, a High Speed Downlink Shared Channel dataframe that includes a second number of packet data unit octets, thesecond number being equal to or less than the first number; andtransferring the High Speed Downlink Shared Channel data frame to thesecond device in an interval.
 7. The method of claim 6, wherein thesecond number is 20 less than the first number, and wherein the methodfurther comprises reusing unused packet data unit octets in a nextinterval.
 8. The method of claim 7, wherein the High Speed DownlinkShared Channel Capacity Allocation control frame includes an informationelement that stores a second value indicating a number of subsequentintervals during which the first device is permitted to use the firstnumber of packet data unit octets, and wherein the reusing occurs whenthe second value is greater than
 1. 9. The method of claim 6, whereinthe High Speed Downlink Channel data frame includes a plurality ofblocks, each block including a group of packet data units, a length ofeach packet data unit in a first block of the plurality of blocks beingdifferent than a length of each packet data unit in a second block ofthe plurality of blocks.
 10. The method of claim 9, wherein the HighSpeed Downlink Shared Channel data frame includes a packet data unit anda logical channel identifier.
 11. The method of claim 6, wherein theHigh Speed Downlink Shared Channel data frame includes a plurality ofpacket data units and a plurality of logical channel identifiers.